You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If called on first timer in queue then subsequent timers get disconnected. Must explicitly disarm the timer first so it's properly removed from queue. This is consistent with esp8266 behaviour.
Also applied to host timer from whence the code originated.
This bug might explain root cause of #2594, where code hangs during intensive timer usage. Specifically, this issue gets triggered if attempting to change the callback on an active timer. (If the timer is inactive then it's not in the queue so doesn't matter.)
Insuring Against Null Pointer in Timer Setup Function
The team has added a safeguard in the timer setup function (os_timer_setfn). Now, if the system encounters something called a 'null pointer', it won't result in an error. This makes the overall codes safer and more robust.
Pre-Emptive Handling of Null Pointer Scenario
The process to handle this 'null pointer' case now occurs earlier, before the timer gets adjusted. This means potential issues are caught and addressed sooner, enhancing the system's reliability.
Disabling Timer Before Modification
The developers have included a new step where the timer is 'disarmed' before being modified. This scheduling tweak improves the accuracy of our timing tasks and enhances the system's performance by ensuring any modifications don't accidentally trigger the timer.
mikee47
changed the title
Bugfix: Rp2040 os_timer_setfn() can stall other timers.
Bugfix: Rp2040 and Host os_timer_setfn() can stall other timers
Oct 11, 2023
If called on first timer in queue then subsequent timers get disconnected.
Must explicitly `disarm` the timer first so it's properly removed from queue.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
mikee47
changed the title
If called on first timer in queue then subsequent timers get disconnected. Must explicitly
disarmthe timer first so it's properly removed from queue. This is consistent with esp8266 behaviour.Also applied to host timer from whence the code originated.
This bug might explain root cause of #2594, where code hangs during intensive timer usage. Specifically, this issue gets triggered if attempting to change the callback on an active timer. (If the timer is inactive then it's not in the queue so doesn't matter.)